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APPEAL BRIEF PURSUANT TO 37 C.F.R. § 41.37 

SIR: 

On April 27, 2009, Appellants submitted a Notice of Appeal from the last 
decision of the Examiner contained in the Final Office Action dated October 29, 2008 in 
the above-identified patent application. 

In accordance with 37 C.F.R. § 41.37, this brief is submitted in support of 
the appeal of the final rejection of claims 11, 12, 14, 16 to 23 and 26. For at least the 
reasons set forth below, the final rejection of claims 11, 12, 14, 16 to 23 and 26 should be 
reversed. 

1. REAL PARTY IN INTEREST 

The real party in interest in the present appeal is Robert Bosch GmbH 
("Bosch"), Postfach 30 02 20, 70442 Stuttgart, Federal Republic of Germany. Bosch is 
the assignee of the entire right, title and interest in the present application. 



2. 



RELATED APPEALS AND INTERFERENCES 



An appeal brief was previously filed for this matter on October 15, 2004, 
and amended on May 22, 2006, resulting in the reopening of prosecution. There are no 
other prior or pending appeals, interferences or judicial proceedings known by the 
undersigned, or believed by the undersigned to be known to Appellants or the assignee, 
Bosch, "which may be related to, directly affect or be directly affected by or have a 
bearing on the Board's decision in the pending appeal." 

3. STATUS OF CLAIMS 

Claims 1 to 10, 13, 15, 24, and 25 have been canceled. 

Claims 11,12, 14, and 16 to 23 stand rejected under 35 U.S.C. § 1 12, H 1, 
as failing to comply with the enablement requirement. 

Claim 26 stands rejected under 35 U.S.C. § 1 12, If 1, as failing to comply 
with the written description requirement. 

Claims 11, 12, 14, 17 to 20, and 23 stand rejected under 103(a) as being 
unpatentable over U.S. Patent No. 6,370,449 ("Razavi"), in view of U.S. Patent No. 
6,512,968 ("de Bellefeuille"). 

Claim 16 stands rejected under 103(a) as being unpatentable over Razavi, 
in view of de Bellefeuille, and in further view of U.S. Patent No. 6,330,499 ("Chou"). 

Claim 21 stands rejected under 103(a) as being unpatentable over Razavi, 
in view of de Bellefeuille, and in further view of U.S. Patent No. 5,465,207 
("Boatwright"). 

Claim 22 stands rejected under 103(a) as being unpatentable over Razavi, 
in view of de Bellefeuille, and in further view of U.S. Patent No. 5,964,813 ("Ishii"). 

Claim 26 stands rejected under 103(a) as being unpatentable over Razavi, 
in view of de Bellefeuille, in further view of Chou, and in further view of Ishii. 

Claims 11, 12, 14, 16 to 21, and 23 stand rejected under 103(a) as being 
unpatentable over U.S. Patent No. 6,185,491 ("Gray"), in view of U.S. Patent No. 
6,246,935 ("Buckley"), and in further view of Chou. 

Appellant appeals from the final rejections of claims 1 to 10, 13, 15, 24, 

and 25. 

A copy of the appeal claims, i.e., claims 1 to 10, 13, 15, 24, and 25, is 
attached hereto in the Claims Appendix. 
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4. STATUS OF AMENDMENTS 

In response to the Final Office Action of October 29, 2008, Appellants 
submitted a Response dated January 23, 2009. However, the Response did not include 
any amendments. 

5. SUMMARY OF CLAIMED SUBJECT MATTER 

Independent Claim 11 

Claim 1 1 relates to a service element, e.g., element 2 of Fig. 1, that belongs 
to a distributed system (e.g., Fig. 1) as a component. See, e.g., Substitute Specification, 
page 4, lines 4-5. The distributed system further includes other components (e.g., Fig. 1, 
elements 3-7) that are independent of one another and interconnected by a bus (e.g., Fig. 1, 
element 1). See, e.g., id. at page 4, lines 5-7. The service element (Fig. 1, element 2) 
includes a processing device for configuring the other components; maintaining the other 
components; performing an error diagnosis of software running on the other components 
and correcting any errors; allowing a remote diagnosis of the other components of the 
distributed system to be carried out, including testing at least one of the other components; 
and performing an emergency function. See, e.g., Fig. 4; Substitute Specification, page 1, 
lines 22-25. 

As described in the Substitute Specification, the service element is either 
provided with its own hardware, i.e., its own processor, or running on an already existing 
processor, in parallel with other software. See, e.g., Substitute Specification, page 3, lines 
28-32. 

Independent Claim 19 

Claim 19 relates a distributed system. See, e.g., Fig. 1. The distributed 
system includes a bus (e.g., Fig. 1, element 1); and components disposed in a motor 
vehicle and connected by the bus and that are independent of each other (e.g., Fig. 1, 
elements 2-7), the components include a service element (e.g., Fig. 1, element 2) that 
includes a processing device for configuring other components, upgrading the other 
components, maintaining the other components, and performing an emergency function. 
See, e.g., Fig. 4; Substitute Specification, page 1, lines 22-25 and page 4, line 26. The 
device further performs an error diagnosis of software running on the other components, 
and, if the software on one of the other components has an error, correcting that software. 
See Substitute Specification, e.g., page 2, lines 13 to 16. It also allows a remote diagnosis 
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of the other components of the distributed system to be carried out, where the remote 
diagnosis includes testing at least one of the other components. See Substitute 
Specification, e.g., page 2, lines 26 to 30 and page 5, lines 13 to 15. 

As described in the Substitute Specification, the service element is either 
provided with its own hardware, i.e., its own processor, or run on an already existing 
processor, in parallel with other software. See, e.g., Substitute Specification, page 3, lines 
28-32. The bus 1 (Fig. 1) may be realized by, e.g., an electrical wiring system, an optical 
system, or may be, e.g., radio-based. See, e.g., Substitute Specification, page 4, lines 9- 
13. In one embodiment, the other components may include, e.g., a memory device 3, a 
communications element 4, a navigation device 5, a DAB (digital audio broadcasting) 
receiver 6, and a display 7. See, e.g., Fig. 1; Substitute Specification, page 4, lines 15-17. 
In another embodiment, the other components may include, e.g., sensors 9, actuating 
mechanisms 10, engine control unit 1 1, an airbag 12, a driver-recognition system having 
locking system 13, a display 22, and a communication element 23. See, e.g., Fig. 2; 
Substitute Specification, lines 16-21. In yet another embodiment, the other components 
may include a heating unit 17, an air conditioning unit 18, a lighting system 19, a smoke 
alarm 20, a security system 21, a display 24, and a communications element 25. See, e.g., 
Fig. 3, lines 4-6. 

Independent Claim 26 

Claim 26 relates to a service element that belongs to a distributed system in 
a motor vehicle as a component, the distributed system including components that are 
independent of one another and interconnected by a bus. See, e.g., Fig. 1 . The service 
element includes a processing device disposed in the motor vehicle and adapted to 
perform operations including the operations of: automatically, and at predefined intervals, 
see, e.g., page 8, lines 6 to 8, performing an error diagnosis of software running on the 
other components, see, e.g., page 2, lines 13 to 16; and for each of a first subset of errors 
diagnosed in the error diagnosis step, repair the error, see, e.g., page 5, lines 17 to 23; and 
for each of a second subset of errors diagnosed in the error diagnosing step, contact a 
provider and allow the provider to responsively remotely repair the error. See Id. 
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6. 



GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 



A. Whether claims 11, 12, 14, and 16 to 23, which stand rejected under 35 
U.S.C. § 1 12, H 1, are enabled. 

B. Whether claim 26, which stands rejected under 35 U.S.C. § 1 12, 1, 
complies with the written description requirement. 

C. Whether claims 11, 12, 14, 17 to 20, and 23, which stand rejected under 
103(a), are patentable over Razavi, in view of de Bellefeuille. 

D. Whether claim 16, which stands rejected under 103(a), is patentable over 
Razavi, in view of de Bellefeuille, and in further view of Chou. 

E. Whether claim 21, which stands rejected under 103(a), is patentable over 
Razavi, in view of de Bellefeuille, and in further view of Boatwright. 

F. Whether claim 22, which stands rejected under 103(a), is patentable over 
Razavi, in view of de Bellefeuille, and in further view of Ishii. 

G. Whether claim 26, which stands rejected under 103(a), is patentable over 
Razavi, in view of de Bellefeuille, in further view of Chou, and in further view of Ishii. 

H. Whether claims 11, 12, 14, 16 to 21, and 23, which stand rejected under 
103(a), are patentable over Gray, in view of Buckley, and in further view of Chou. 

7. ARGUMENTS 

A. Rejection of Claims 11, 12, 14, and 16 to 23 Under 35 U.S.C. § 112, f 1 

Claims 11, 12, 14, and 16 to 23 were rejected under 35 U.S.C. § 1 12, If 1, 
as failing to comply with the enablement requirement. 

With regard to claims 1 1 and 19, the Examiner believes that the 
specification does not adequately describe "performing an error diagnosis of software 
running on the other components" and "allowing a remote diagnosis of the other 
components of the distributed system to be carried out, wherein the remote diagnosis 
includes testing at least one of the other components." Specifically, the Examiner objects 
to (1) "not mentioning any steps to be carried out regarding the test" and (2) that "it [is] 
unclear . . . how the remote diagnosis and testing are indeed different from each other." 
The Examiner further states that "one having ordinary skill in the art would not be able to 
perform both remote testing and remote diagnosis without undue experimentation as one 
having ordinary skill in the art would consider testing and diagnosis to often cover the 
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same thing and therefore would turn to the specification for clarification." Advisory 
Action of February 4, 2009. 

Appellants respectfully assert that one of ordinary skill in the art would be 
able to implement the claimed subject matter without undue experimentation. Component 
diagnosis/testing is known in the art and dependent on the specific device being 
diagnosed/tested. The invention is not "performing an error diagnosis" in-and-of-itself, 
but rather the entire claimed subject matter. To that end, the "performing an error 
diagnosis" is in accordance with the specific implementation of the invention, but a 
diagnosis/testing itself for any particular implementation would be understood by one of 
ordinary skill in the art, without having to perform undue experimentation. 

Specifically, with regard to the feature of "allowing a remote diagnosis of 
the other components of the distributed system to be carried out, wherein the remote 
diagnosis includes testing at least one of the other components." It is quite clear that 
"testing . . . other components" is part of (e.g., a subset of) "a remote diagnosis of the 
other components." This is consistent with the specification that recites "service element 
2 allows a service provider to carry out a remote diagnosis of the individual components, 
using communication means 4. This service provider can then test the individual 
components directly, using communication means 4 and service element 2." Substitute 
Specification at page 5, lines 13-15 (emphasis added). Moreover, it is understood from 
the plain meaning of the terms that testing is a subset of carrying out remote diagnosis. To 
perform a diagnosis means to identify the nature or cause of a phenomenon. A step in 
performing such identification may include performing a test. 

The present invention is to a novel arrangement of electrical components 
that allows for remote diagnosis/testing. The actual diagnosis routines and test routines 
are well known in the art, and selected based on context of specific implementation. This 
known feature does not render the inventive arrangement as lacking enablement, since a 
person of ordinary skill in the art would not require undue experimentation to select the 
appropriate diagnosis routines and tests for a specific implementation. 

Reversal of this enablement rejection of claims 11, 12, 14, and 16 to 23 is 
therefore respectfully requested. 
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B. Rejection of Claim 26 Under 35 U.S.C. § 112, f 1 

Claim 26 was rejected under 35 U.S.C. § 1 12, If 1, as failing to comply with 
the written description requirement. 

Claim 26 recites "[a] service element that belongs to a distributed system in 
a motor vehicle as a component the distributed system further including other 
components that are independent of one another and interconnected by a bus." Original 
claim 1 provides support for these features. In this regard, original claim 1 recited "[a] 
service element, wherein the service element (2, 15, 16) is a component of a distributed 
system, the components of the distributed system being independent of one another and 
interconnected by a bus ..." 

Claims 26 further recites "a processing device disposed in the motor 
vehicle and adapted to perform operations^ Support for these features may be found in 
the Substitute Specification, e.g., at page 3, lines 30 to 33, which states "the component 
either being provided with its own hardware, i.e. its own processor, or running on an 
already existing processor, in parallel with other software, if this processor allows another 
component to do this." 

Claim 26 further recites "automatically, and at predefined intervals, 
performing an error diagnosis of software running on the other components." Support for 
these features may be found in the Substitute Specification, e.g., at page 7, line 6, which 
states that "[i]n regular intervals, service element 2 checks the components." Also, at page 
3, lines 25 to 28, the Substitute Specification states "the present invention provides for a 
service element being used, which automatically configures components, performs 
maintenance tasks, and, in particular, updates individual components with new software 
versions, and, if necessary, automatically executes an emergency function as well, without 
the user having to intervene." 

Claim 26 further recites 'for each of a first subset of errors diagnosed in 
the error diagnosis step, repair the error; and for each of a second subset of errors 
diagnosed in the error diagnosing step, contact a provider and allow the provider to 
responsively remotely repair the error." Support for these features may be found in the 
Substitute Specification, e.g., at page 5, lines 17 and 18, which states that "[s]ervice 
element 2 also contacts the service provider, using communication element 4, when 
service element 2 can no longer eliminate an error itself." Additionally, page 5, lines 13 to 
15, states that "service element 2 allows a service provider to carry out a remote diagnosis 
of the individual components, using communication element 4. This service provider can 
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then test the individual components directly, using communication element 4 and service 
element 2." Additionally, page 5, lines 19 and 20 (emphasis added), states that "if the 
component in question can also no longer be repaired using the remote diagnosis of the 
service provider, then the service provider contacts the user of the distributed system." 
The above provided sections of the specification clearly describe errors the component can 
repair/fix/eliminate by itself, and a second group of errors that cause a provider to be 
contacted for repair. 

It is clear that Appellants had possession of each element of claim 26 at the 
time of filing. Further, as each cited reference deals with the service element, remote 
provider, and the interrelationship of the two, it is clear from the cited portions of the 
specification that Appellants had possession of this very combination of features now 
found in claim 26. 

Reversal of this written description rejection of claim 26 is therefore 
respectfully requested. 

C. Rejection of Claims 11, 12, 14, 17 to 20, 
and 23 Under 35 U.S.C. § 103(a) 

Claims 11, 12, 14, 17 to 20, and 23 stand rejected under 35 U.S.C. § 103(a) 
as being unpatentable over Razavi, in view of de Bellefeuille. 

Claims 1 1 and 19, as well as their dependent claims, should be allowed 
because neither Razavi nor de Bellefuille discloses the feature of "performing an 
emergency function." The Examiner refers to col. 1, lines 41-46 and col. 7, lines 54-63 of 
Razavi as assertedly disclosing this feature. However, col. 1, lines 41-46, the 
"background" section of Razavi that discusses traditional automobile design, states: 
"designers may also incorporate into the vehicle the delivery of services that may assist 
the driver, thereby reducing the driver's workload and anxiety level. Such services may 
include providing computerized maps, navigation aids and emergency assistance 
signaling." First, this does not disclose "a processing device disposed in the motor 
vehicle and adapted to perform operations including the operations of: . . . performing an 
emergency function." Since this section discusses "traditional" automobile designs, and 
does not further elaborate on "emergency function," the disclosure is likely referring to 
simple hazard signal lights, which does not require any processing device adapted to 
perform operations including performance of an emergency function. In any event, it does 
not identically disclose "a processing device ... to perform ... an emergency function." 
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Second, even if one assumed that this did disclose "performing an emergency function," it 
does not form any part of any embodiment of Razavi. In this hypothetical case, it would 
actually teach away from the combination, because while Razavi discusses emergency 
assistance signaling in the background section, Razavi, nevertheless, omits any such 
feature from the embodiments of the Razavi disclosure. 

The Examiner argues that this "refers to emergency assistance signaling as 
one particular delivery of services to the user which are described throughout the 
disclosure as network-based services (see, for example, column 5, lines 9-35) and are also 
described as being performed by a processing device, along with a map service, in column 
7, lines 54-63." However, this characterization is simply incorrect. It may be true that 
col. 5, lines 9 to 35 and col. 7, lines 54-63 discuss network based services and services 
provided by a processor, but the services discussed in these sections have absolutely 
nothing to do with "performing an emergency function," and merely discloses text-to- 
speech and computerized maps. It seems that the Examiner is arguing that since the 
background section of Razavi discloses a prior art service of "emergency assistance 
signaling," and since embodiments of Razavi disclose computerized services such as text- 
to-speech, that Razavi discloses a "processing device ... to perform ... an emergency 
function." This assertion is not logically sustainable. Razavi may disclose prior art 
"emergency assistance signaling," and further disclose other computerized services, but 
this simply does not disclose the feature of a "processing device ... to perform ... an 
emergency function." 

Independent of the above, claims 1 1 and 19, as well as their dependent 
claims, should be allowed because neither Razavi nor de Bellefuille disclose the feature of 
"a processing device disposed in the motor vehicle and adapted to perform operations 
including the operations of: configuring the other components; maintaining the other 
components; . . ." The Examiner asserts that Razavi discloses a service element that 
maintains other components and de Bellefuille discloses that maintenance may include 
performing an error diagnosis. Specifically, the Examiner asserts that col. 6, lines 9-17 
and col. 8, lines 50-67 of Razavi disclose a service element that maintains other 
components. The "Examiner asserts that Razavi discloses a service element that is the 
central component of the in-car sub-network that handles the processing and programming 
functions of the other components on the network." Final Office Action at page 26. First, 
this characterization of these sections of Razavi makes no mention of "maintaining," just 
as the sections themselves makes no mention of "maintaining." Additionally, even if 
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"processing and programming" identically disclosed "maintaining," these sections of 
Razavi simply do not disclose "processing and programming." Col. 6, lines 9-17 merely 
states that all devices are either directly or indirectly plugged into the compute platform. 
This neither states nor implies that the compute platform "handles the processing and 
programming functions of the other components." 1 Further, col. 8, lines 50-67 merely 
identifies JVM as the execution environment for the compute platform. This may disclose 
that any application running on the compute platform will run in Java, but does not 
disclose the compute platform processing, programming, or maintaining the connected 
devices. 

Nowhere in these two sections or any other section of Razavi is "a 
processing device disposed in the motor vehicle and adapted to perform operations 
including the operations of: configuring the other components; maintaining the other 
components; . . ." disclosed. For example, at Razavi, col. 2, lines 14 to 15, "re- 
configuring and upgrading of the vehicle" is disclosed. However, this discloses upgrading 
the overall vehicle by interchanging parts, and not upgrading (or otherwise maintaining) 
those parts. Razavi, at col. 3, lines 33-37, likewise discloses upgrading the vehicle by 
exchanging devices, and not upgrading (or otherwise maintaining) the devices. Razavi, at 
col. 5, lines 26-29, discloses that the system "allows new components or new software to 
be added to the automobile sub-network and thereby enables new services to be provided 
to the driver." However, this again does not disclose "a processing device disposed in the 
motor vehicle and adapted to perform operations including the operations of: configuring 
the other components; maintaining the other components; . . ." "New components" again 
refers to the exchange of devices connected to the network, and "new software" may refer 
to any number of things, and does not disclose any particular device "maintaining" other 
components with "new software." For example, Razavi, at col. 10, lines 26-31, discloses 
that "server 53 allows the services which are provided to be upgraded or otherwise 
modified, whereas services provided by many embedded servers are 'hard wired' into 
them, thereby limiting their capabilities and their upgradeability." Here, as in the last 
cited section of Razavi, the "upgrading" is being performed on the central component, and 
not on the "other components." 



For example, all computers on a network are connected to some number of switches/routers, but the 
switches/routers do not perform the processing for the computers, do not perform the programming for the 
computers, and do not perform "maintenance" on the computers. 
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Of the many references in Razavi to upgrading, replacing, re-configuring, 
or otherwise performing a task (e.g., the four examples provided above); only one 
reference is made to "upgrading" an existing connected device (i.e., other than the central 
device). Razavi, at col. 13, lines 54-64, states that "components which execute associated 
software, display data or provide services can be upgraded by downloading new software, 
data or services ('upgrade data') to the components through the in-car sub-network . . . 
The software can be retrieved by one device (e.g., a wireless modem,) conveyed through 
the network and installed in a second device (e.g., a GPS locator) . . ." However, there is 
absolutely no mention of what device does the "installing] in a second device." The 
compute platform 22 (i.e., the alleged processing device of claims 1 1 and 19) is not 
mentioned anywhere in this section. Further, if it is argued that earlier disclosure indicates 
that the modem and GPS must both be connected to the compute platform, Razavi still 
fails to disclose the present features for at least two reasons. First, Razavi states that 
devices are connected to the compute platform directly or via a network (e.g., Ethernet). 
Therefore, the GPS may be directly connected to the modem, indirectly connected to the 
compute platform via a network, and perform this "upgrade" directly with the modem 
(i.e., with no involvement from the compute platform). Second, even if one assumes all 
devices are directly connected to the compute platform, Razavi only refer to that which is 
"conveyed through the network." Conveying data is the function of a switch or router, 
and does not constitute "maintaining" or "configuring" the device to which data is merely 
conveyed. 

As explained above, in great detail, though several sections of Razavi refers 
to upgrading, absolutely no section discloses "a processing device disposed in the motor 
vehicle and adapted to perform operations including the operations of: configuring the 
other components; maintaining the other components; . . ." 

de Bellefuille does not, and was not asserted to disclose this feature. For at 
least these reasons the combination of Razavi and de Bellefuille fails to identically 
disclose or suggest each feature of claims 1 1 and 19. Therefore, claims 1 1 and 19, as well 
as their dependent claims, should be allowed. 

In this regard, it is noted that claims 1 1 and 19 provides a novel step-wise 
approach to component maintenance, by providing a service element in a distributed 
system to handle initial maintenance and testing of other components of the distributed 
system and that also provides further remote diagnosis, e.g., where the service element is 
unable to perform the diagnosis. 



11 



For at least the foregoing reasons, Razavi in view of de Bellefuille does not 
render claims 1 1 and 19 obvious. Claims 12, 14, 17-18, 20, and 23 depend from one of 
claims 1 1 and 1 9 and are therefore allowable for at least the same reasons as claims 1 1 and 
19, respectively. 

Reversal of this obviousness rejection of claims 11, 12, 14, 17 to 20, and 23 
is therefore respectfully requested. 

D. Rejection of Claim 16 Under 35 U.S.C. § 103(a) 

Claim 16 stands rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Razavi, in view of de Bellefeuille, and in further view of Chou. 

Claim 1 6 depends from allowable claim 1 1 and is therefore allowable for at 
least the same reasons as claim 1 1 , since Chou does not correct the critical deficiencies of 
the combination of Razavi and de Bellefeuille noted above in support of the patentability 
of claim 1 1 . 

Reversal of this obviousness rejection of claim 16 is therefore respectfully 

requested. 

E. Rejection of Claim 21 Under 35 U.S.C. § 103(a) 

Claim 21 stands rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Razavi, in view of de Bellefeuille, and in further view of Boatwright. 

Claim 21 depends from allowable claim 1 1 and is therefore allowable for at 
least the same reasons as claim 1 1 , since Boatwright does not cure the critical deficiencies 
of Razavi and de Bellefeuille noted above in support of the patentability of claim 1 1 . 

Reversal of this obviousness rejection of claim 21 is therefore respectfully 

requested. 

F. Rejection of Claim 22 Under 35 U.S.C. § 103(a) 

Claim 22 stands rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Razavi, in view of de Bellefeuille, and in further view of Ishii. 

Claim 22 depends from allowable claim 1 1 and is therefore allowable for at 
least the same reasons as claim 1 1 , since Ishii does not cure the critical deficiencies of 
Razavi and de Bellefeuille noted above in support of the patentability of claim 1 1 . 

Reversal of this obviousness rejection of claim 22 is therefore respectfully 

requested. 
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G. Rejection of Claim 26 Under 35 U.S.C. § 103(a) 

Claim 26 stands rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Razavi, in view of de Bellefeuille, in further view of Chou, and in further view of 
Ishii. 

Claim 26 includes subject matter analogous to that discussed above in 
support of the patentability of claim 1 1, so that claim 26 is a allowable for at least 
essentially the same reasons as claim 1 1 , since, as noted above, Ishii does not correct the 
critical deficiencies of the combination of Razavi and de Bellefeuille noted above in 
support of the patentability of claim 1 1 . 

Reversal of this obviousness rejection of claim 26 is therefore respectfully 

requested. 

H. Rejection of Claims 11, 12, 14, 16 to 21, 
and 23 Under 35 U.S.C. § 103(a) 

Claims 11, 12, 14, 16 to 21, and 23 stand rejected under 103(a) as being 

unpatentable over Gray, in view of Buckley, and in further view of Chou. 

Each of claims 1 1 and 19 recites, inter alia, the following: 

performing an error diagnosis of software running on the 
other components, and, if the software on one of the 
other components has an error, correcting that software; 

Essentially, as discussed in detail below, Gray discloses a control center 

device connected to other devices, where the control center device includes a software 

interface (within the control center device) that is used by the control center device to 

communicate with an associated other device. It is this interface, within the control center 

device, that is upgraded/maintained. The Examiner contends that the upgrading of the 

interface associated with a peripheral device, but installed on and used by the control 

center, amounts to the control center upgrading other devices. This is simply not 

sustainable, as the upgrading is clearly that of the control center. There is absolutely no 

upgrading of the other device, but merely a part of the control center that interfaces with 

the other device. 

The Examiner asserts that Gray discloses a service element that maintains 
other components and that Buckley discloses the precise error diagnosis of claims 1 1 and 
19. However, nowhere does Gray disclose a service element that maintains other 
components as provided for in the present claims. For example, the Examiner refers to 
col. 4, line 65 to col. 5, line 21 of Gray as disclosing a service element that performs 
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upgrading and maintenance of other components on a distributed system to which the 
service element belongs. However, neither this section, nor any other section of Gray, 
discloses a service element that maintains other components. What Gray does disclose is 
a vehicle control center that is connected to one or more devices. In order for the vehicle 
control center to "control" a new device that is connected to the vehicle control center, the 
vehicle control center needs an "interface" for that device. "In the simplest 
implementation, illustrated [in FIG. 5], a memory device such as ROM 510 stores 
information about the device and in addition, in one embodiment, contains a plurality of 
JavaBeans 520 for uploading to the vehicle control center over bus 120." Gray at col. 4, 
lines 23-31 (emphasis added). At page 30 of the Final Office Action, "the Examiner 
asserts that Gray explicitly discloses upgrading/maintaining the interfaces of the other 
components by receiving software upgrades/updates via a port of the vehicle control 
center and, as such, the vehicle control center (i.e. service element) in Gray performs the 
operation of maintaining the other components, specifically [col. 4, line 65 to col. 5, line 
21 states]: 

As an alternative to storing a control bean 750 and a GUI 
bean 760 or other beans associated with the standard device 
interface 740, the memory device or ROM may store a 
network address such as a uniform resource locator (URL) 
from which the appropriate manufacturer's interface may be 
downloaded. This permits the manufacturer to update a user 
interface on a dynamic basis and ensure that the most recent 
version of the manufacturer device interface is downloaded 
when a device is installed. This also reduces the ROM space 
required for storing the manufacturer's interface information 
and reduces the cost of the attached end device. 

One should note that there are a number of ways in which 
the standard device interfaces or custom interfaces can be 
installed in the vehicle control center. They can be pre- 
installed in the vehicle control center when it is installed in the 
vehicle. Additionally, they can be requested and downloaded 
from the attached devices as described more hereinafter. They 
can be loaded from a diskette, CDROM, EPROM or other 
memory medium into the vehicle control center. They can be 
received over a network link from a URL address which 
address is either downloaded from the attached device or 
entered manually, and they can be input over an I/O link, such 
as an infrared port to the vehicle control center." 

(Emphasis added.) 

FIG. 5 of Gray refers to uploading the device interface stored in ROM 510 
to the vehicle control center, and FIG. 7 contrasts that by referring to storing a URL for 
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the interface location instead of the interface, so that the vehicle control center can upload 
the URL from the device and download the interface from the location specified by the 
URL. This says nothing about downloading the interface to the device, and in fact, merely 
discloses the vehicle control center downloading the interface, to "be installed in the 
vehicle control center." Additionally, Gray states that the URL embodiment "reduces 
the ROM space required for storing the manufacture's interface information." In FIG. 5, 
the ROM is described as storing the interface (i.e., to upload to the vehicle control center), 
and, in FIG. 7, the ROM is described as storing a URL (i.e., indicating where the vehicle 
control center may retrieve the interface). Presumably, the URL is smaller in size than the 
interface and thus Gray states that FIG. 7 "reduces the ROM space required." However, 
if, as the Examiner contends, the URL is uploaded to the vehicle control center so that the 
vehicle control center can download the interface, only to further download the interface 
to the device (a step wholly absent from the disclosure), then the ROM would require 
more storage space than a ROM that only held the interface. 

FIGS. 10A-D further support this, illustrating the vehicle control center 
with an A interface and a B interface, attached to device A and device B. Device C, which 
stores interface C, is connected to the bus, and responsive to a request, uploads interface 
C to the vehicle control center. This is again illustrated in FIGS. 1 1 A, 1 IB, and 12. 
Nowhere in Gray does the vehicle control center, nor any other device, download to the 
"other components" a new interface. The only thing sent to the components is a request 
for an upload. See Gray, col. 4, line 65 to col. 5, line 21, as cited in the Final Office 
Action. 

Thus, the system of Gray in view of Buckley, and in view of Chou, does 
not disclose or suggest these features of either of claims 1 1 and 19. 

Each of claims 1 1 and 19 also recites, inter alia, "allowing a remote 
diagnosis of the other components of the distributed system to be carried out, wherein the 
remote diagnosis includes testing at least one of the other components." 

As regards this feature, neither Gray nor Buckley discloses "the remote 
diagnosis includes testing at least one of the other components." Instead, the Examiner 
relies on Chou at col. 3, lines 15-31 and col. 5, lines 34-35. However, the remote service 
center 200 (including diagnostic server 201) is thoroughly discussed at Chou col. 5, line 
33 to col. 6, line 47, and does not mention "wherein the remote diagnosis includes testing 
at least one of the other components." "Diagnostic server 201 [may have] access to data 
related to the vehicle such as history, as-built, diagnostics, warranty, service information 
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and failure mode data." (Chou, col. 5, lines 35-37.) The section goes on to further 
describe data collection and modeling, but nowhere does Chou disclose a "remote 
diagnosis [that] includes testing at least one of the other components." 

For all of the foregoing reasons, the combination of Gray, Buckley, and 
Chou does not render disclose or suggest all of the features of either of claims 1 1 and 19, 
so that the combination of Gray, Buckley, and Chou does not render unpatentable either of 
claims 1 1 and 19. Claims 12, 14, 16 to 18, 20, 21, and 23 depend from one of claims 1 1 
and 19, so that claims 12, 14, 16 to 18, 20, 21, and 23 are allowable for at least the same 
reasons as claims 11 and 19, respectively. 

Reversal of this obviousness rejection of claims 12, 14, 16 to 18, 20, 21, 
and 23 is therefore respectfully requested. 

8. CLAIMS APPENDIX 

a "Claims Appendix" is attached hereto and appears on the pages labeled 
"Claims Appendix." 

9. EVIDENCE APPENDIX 

No evidence has been submitted pursuant to 37 C.F.R. §§ 1.130, 1.131 or 
1 .132. No other evidence has been entered by the Examiner or relied upon by Appellants 
in the appeal. An "Evidence Appendix" is nevertheless attached hereto. 

10. RELATED PROCEEDINGS APPENDIX 

As indicated above in Section 2, above, "[a]n appeal brief was previously 
filed for this matter on October 15, 2004, and amended on May 22, 2006, resulting in the 
reopening of prosecution. There are no other prior or pending appeals, interferences or 
judicial proceedings known by the undersigned, or believed by the undersigned to be 
known to Appellants or the assignee, Bosch, 'which may be related to, directly affect or be 
directly affected by or have a bearing on the Board's decision in the pending appeal.'" As 
such, there are no "decisions rendered by a court or the Board in any proceeding identified 
pursuant to [37 C.F.R. § 41.37(c)(1)(h)]" to be submitted. A "Related Proceedings 
Appendix" is nevertheless attached hereto. 
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11. CONCLUSION 

For at least the reasons indicated above, Appellants respectfully submit that 
the art of record does not disclose or suggest Appellants' invention as recited in the claims 
of the above-identified application. Accordingly, it is respectfully submitted that the 
invention recited in the claims of the present application is new, non-obvious and useful. 
Reversal of all of the Examiner's rejections of the claims is therefore respectfully 
requested. 

Respectfully submitted, 



Dated: July 23, 2009 By: /Aaron Grunberger/ 

Aaron Grunberger (Reg. No. 59,210) for: 
Gerard A. Messina 
Registration No. 35,952 

KENYON & KENYON LLP 
One Broadway 
New York, NY 10004 
(212) 425-7200 
CUSTOMER NO. 26646 
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CLAIMS APPENDIX 

11. A service element that belongs to a distributed system in a motor vehicle as a 
component, the distributed system further including other components that are 
independent of one another and interconnected by a bus, the service element comprising: 

a processing device disposed in the motor vehicle and adapted to perform 
operations including the operations of: 

configuring the other components; 
maintaining the other components; 

performing an error diagnosis of software running on the other components, and, if 
the software on one of the other components has an error, correcting that software; 

allowing a remote diagnosis of the other components of the distributed system to 
be carried out, wherein the remote diagnosis includes testing at least one of the other 
components; and 

performing an emergency function. 

12. The service element according to claim 11, wherein the processing device is 
further adapted to perform the operations of: 

detecting a new component and for integrating the new component into the 
distributed system; and 

operating a display device to represent information about a configuration. 

14. The service element according to claim 11, wherein at least one of the 
maintaining operation and the correcting operation includes communicating with a 
communication element for loading new software for the other components. 

16. The service element according to claim 11, wherein the processing device is 
further adapted to perform the operations of : 

communicating with a communications element for, in the case of a serious 
functional error, contacting a service provider. 

17. The service element according to claim 11, wherein the processing device is 
further adapted to perform the operations: 

operating a display to transfer information about the distributed system to a user of 
the distributed system. 
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18. The service element according to claim 11, wherein the processing device is 
further adapted to perform the operations of: 

checking newly loaded software in accordance with a predetermined value. 

19. A distributed system, comprising: 
a bus; and 

components connected by the bus, the components being independent of each other 
and being disposed in a motor vehicle, one of the components being a service element that 
includes: 

a processing device adapted to perform operations, the operations 
including: 

configuring the other components, 
maintaining the other components, 

performing an error diagnosis of software running on the other 
components, and, if the software on one of the other components has an 
error, correcting that software; 

allowing a remote diagnosis of the other components of the 
distributed system to be carried out, wherein the remote diagnosis includes 
testing at least one of the other components; and 

performing an emergency function. 

20. The distributed system according to claim 19, wherein: 

at least one of the other components includes a communication element. 

21. The service element according to claim 14, wherein the communications 
element includes a transceiver station communicating over a radio channel. 

22. The service element according to claim 11, wherein the error diagnosis is 
performed at a predefined time interval. 

23. The service element according to claim 11, wherein the bus includes one of an 
electrical wiring system, an optical wiring system, and a radio based system. 
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26. A service element that belongs to a distributed system in a motor vehicle as a 
component, the distributed system further including other components that are 
independent of one another and interconnected by a bus, the service element comprising: 

a processing device disposed in the motor vehicle and adapted to perform 
operations including the operations of: 

automatically, and at predefined intervals, performing an error diagnosis of 
software running on the other components; 

for each of a first subset of errors diagnosed in the error diagnosis step, 
repair the error; and 

for each of a second subset of errors diagnosed in the error diagnosing step, 
contact a provider and allow the provider to responsively remotely repair the error. 
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EVIDENCE APPENDIX 

No evidence has been submitted pursuant to 37 C.F.R. §§1.130, 1.131, or 1.132. 
No other evidence has been entered by the Examiner or relied upon by Appellants in the 
appeal. 
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RELATED PROCEEDINGS APPENDIX 

As indicated above in Section 2, above, "[a]n appeal brief was previously filed for 
this matter on October 15, 2004, and amended on May 22, 2006, resulting in the reopening 
of prosecution. There are no other prior or pending appeals, interferences or judicial 
proceedings known by the undersigned, or believed by the undersigned to be known to 
Appellants or the assignee, Bosch, 'which may be related to, directly affect or be directly 
affected by or have a bearing on the Board's decision in the pending appeal.'" As such, 
there are no "decisions rendered by a court or the Board in any proceeding identified 
pursuant to [37 C.F.R. § 41.37(c)(l)(ii)]" to be submitted. 
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